MRTC Industrial IT day 29 mars 2001

The purpose of this white paper is to describe the experience gained by Enea OSE System during certification of the OSE RTOS to the international standard IEC 61508 and the experience from on-going projects to show certifiability to the RTCA standard DO-178B. The goal is also to show that COTS can be used within safety systems, if the product has the artifacts required to be certifiable to these international standards. OBSERVERA! Denna artikel innehåller i original jämförelser mellan IEC 61508 och RTCA/DO-178B. Den har kortas för att få plats i nyhetsbrevet. Kontakta författarna på epost om du vill ha en fullständig version av artikeln. Introduction There is a general uncertainty within the software industry to what degree COTS technology has the potential or not to deliver high quality products and add value for money to customers that requires products to be certifiable to an international safety standard. Enea OSE Systems has developed the OSE RTOS (Real-Time Operating Systems) as a Commercial Off The Shelf product for the telecommunication/datacommunication and the safety industry for more than ten years. As the requirements from the telecommunication industry increases regarding performance and high-availability, the OSE RTOS product requirements suites the requirements for safety certifiability more and more. Therefore the OSE RTOS has been able to be certified to the IEC 61508 standard and certifiable (currently on-going project) to the RTCA/DO-178B standard. The challenge to show certifiability of the OSE COTS RTOS to these international standards has also provided Enea OSE Systems with experience on how these standard comply to each other and what the main differences are between them. To be able to certify OSE COTS products to these standards Enea OSE Systems has developed a certification development model that comply to both standards. Customers using a COTS product have some advantages and some disadvantages by using COTS products. These effects has to be evaluated by the customer before taking a decision to use a COTS product or not in the system. It is the Enea OSE Systems experience from these certification activities that are addressed in this paper. Sida 6 Nyhetsbrev nr 2-2001 Svenska ENCRESS-klubben Challenges when certifying a COTS product Acronyms usedDefinitions In the table below we list the most common used acronyms and definitions within the software industry, [1] [2] [3]. Acronym Definitions Comment CAS Commercially Acquired Software Another acronym for COTS that is a software product. CDI Commercially Developed Items Product developed for commercial use, i.e. COTS. COTS Commercial Off The Shelf COTS are special case of NDI and are sometimes referred to CDI [1]. GOTS Government Off The Shelf Products owned and/or developed by governmental organization. MOTS Modifiable Off The Shelf The product is modifiable to some degree for the customer. Military Off The Shelf Product owned and/or developed by military organization. NDI Non-Developmental Item The acronym NDI also include GOTS products [1]. OTS Off The Shelf The same as COTS. PDS Previously Developed Software Any Software developed for use on another application. PDS is used in the DO-178B standard. Table 1. Acronyms used within the software industryDefinitions PDS covers only Software products and is used within the DO-178B standard. PDS include COTS products and software developed to previous or current software/safety standards, which may include legacy software. NDI include both hardware and software products (i.e. mircoprocessors, ASICs, operating systems, middleware, development tools and compilers etc.) available from commercial sources which will fulfill a specific task or role with or without requiring modifications. The use of COTS product within a company change the focus of software engineering practice to include the following areas to be consider when using a COTS product in a system: !"identification !"qualification !"adaptation !"integration/assembly !"upgrade (for system evolution) This concept, COTS-Based Systems (CBS), has been developed by Software Engineering Institute. A method to classify the different types of COTS products when acquiring a COTS products is described in reference [3]. Advantages and disadvantages when using COTS products in safety systems The usage of COTS (the acronym PDS is used as the OSE product is a pure Software product) products in safety systems is related to some advantages and disadvantages for the customer. In the table below we have listed the advantages and disadvantages when using PDS products in safety systems (the list should be applicable for any system). Svenska ENCRESS-klubben Nyhetsbrev nr 2-2001 Sida 7 Advantages Disadvantages PDS is an existing product, i.e. the product has been used in existing systems by many customers (i.e. many hours of execution – proven in use) PDS may or may not be designed for a particular environment of the safety system The cost and the time to market are reduced by using a PDS. PDS generally contain functionality which is not required by the safety system The development environment and tools are usually supported by the PDS supplier or its partners PDS may or may not have documentation for third party review The core knowledge for the PDS is handled by the PDS supplier (i.e. the customer can focus on his core knowledge) PDS usually do not have a configuration control process or sufficient traceability of changes. Technological evolution and development of the PDS is handled by the PDS supplier PDS are not rigorously tested to their potentially critical importance Support is handled by the PDS supplier PDS do not (in general) provide access to source code Table 2. Advantages and disadvantages when using COTS products in safety system Generally there are basically three approaches to deal with NDI in safety systems [1], !"Ignore the NDI (i.e. don’t use the NDI) !"Analyze and test the NDI (usually performed by the vendor) !"Isolate the NDI (use the NDI in a untrustworthy way and ensure that the NDI will not impact the safety critical requirements) A mixture of these approaches can be used in a particular system. A general method to check the suitability of a COTS product within a system is described in [4]. The approach for Enea OSE System has been to show certifiability of its safety products (currently the RTOS kernel and the memory management system) to the international standards IEC 61508 and RTCA/DO-178B. This means that Enea OSE Systems provide the vendor with all the advantages of a PDS and provide the vendor with the necessary evidence that the PDS has been analyzed and tested to the level of criticality it will be used within. This paper will further on describe how Enea OSE Systems has handled the disadvantages with using COTS in safety system. OSE certification model To be able to show certifiability to both IEC 61508 and DO-178B for a COTS product Enea OSE System faced the following challenges: !"Identifying the activities in the IEC 61508 and DO-178B necessary to be re-engineered to be able to comply to the standards for a COTS product !"Develop a common certification model within Enea OSE Systems to be able to run certification projects to both standards and be able to reuse result from certification activities between the standards. !"Develop a common set of documents to execute certification projects. The OSE certification model focusing on re-engineering of requirements as requirements is the base to capture the product functionality to be certifiable and to be able to show test result to comply to both standards. The strategy for the testing has been to develop automated test systems to make both regression testing easier and reuse for new products to be certified in the future. In the figure below the OSE certification model is described. 1 A recommended test technique to test a COTS product are fault injection. Sida 8 Nyhetsbrev nr 2-2001 Svenska ENCRESS-klubben Figure 1. The OSE certification model The following document model for planning the project was defined for certification project. Figure 2. Planning document model for certification projects The IEEE standard was chosen to provide the common content for the SQAP (Software Quality Assurance Plan), SCMP (Software Configuration Management Plan) and SVVP (Software and safety Verification and Validation Plan) documents. The content of the PSAC (Plan for Software Aspects of Certification) and SAS (Software Accomplishment Summary) document used within Enea OSE Systems is based on experienced gather by TekSci Inc. The content of Project Specification is based on internal requirements for defining a project within Enea OSE Systems. All the project planning documents has appendix that provide a mapping of the content for the document to the associated requirements in IEC 61508 and DO-178B. The product documents used within the certification model are: !"SRS (Software Requirement Specification) !"SDS (Software Design Specification), if applicable, i.e. required when a portion of new developed code has to be added to the certifiable COTS product !"STS (Software Test Specification) !"STR (Software Test Result) !"SM (Safety Manual) !"Traceability Matrix !"VDD (Version Description Document), i.e. the configuration index 2 IEEE Std 730-1989 was used for the SQAP document, IEEE Std 828-1990 was used for the SCMP document and IEEE Std 1059-1993 was used for the SVVP document PSAC Project Spec. SQAP SCMP SVVP Re-engineering of requirements Code review and analysis Re-engineering of test and test systems Testing according to applicable Safety level Proof, Certif-iability Development of all SW life cycle data